Databases are used to store information. Databases are frequently organized, or modeled, based on an abstraction referred to as an “entity.” Each entity models a thing that is relatively distinct from another thing. One example is that of a company database. For example, a company database may be organized based at least in part on an employee entity which is used to model employees of the company, an office entity which is used to model office space of the company, and a desk entity used to model desks used by its employees.
An entity is typically implemented in tangible form via a corresponding entity structure. Thus, in the example above, the company database may include an employee entity structure, an office entity structure and a desk entity structure. Each entity structure includes entity instances that correspond to a particular thing being modeled. Thus, the employee entity structure has a number of employee entity instances, each of which corresponds to a particular employee, the office entity structure has a number of office entity instances, each of which corresponds to a particular office, and the desk entity structure has a number of desk entity instances, each of which corresponds to a particular desk.
It may be beneficial to understand the relationships between entity instances of a pair of entity structures in a database. However, there may be no information in the database that directly identifies the relationships between entity instances of one entity structure and the entity instances of a second entity structure. Consequently, generating relationship data, such as a relationship table, that identifies the relationships between entity instances of one entity structure and the entity instances of a second entity structure may be a largely manual process, requiring human knowledge about the entity instances stored in the database, and requiring human input to generate such a structure. This can be time-consuming and therefore costly.
Sometimes the relationship between entity instances in one entity structure and entity instances in another entity structure is necessarily one-to-one. For instance, the company may be structured such that each office has only a single desk, and any desk can only be in one office. Similarly an employee may be associated with at most one office, and each office may only be associated with one employee. Groups of entity structures so related may be referred to as a one-to-one (“1:1”) entity structure group. Some of the relationships between two entity structures in a 1:1 entity structure group may be identified in the database, and others not. For example, in the above 1:1 entity structure group, an employee-office relationship table might identify for each particular employee entity instance in the employee entity structure the particular office entity instance in the office entity structure with which the particular employee entity instance is related. Further an office-desk relationship structure might identify for each particular office entity instance in the office entity structure the particular desk entity instance in the desk entity structure with which the particular office entity instance is related. However, it may be desirable to have an employee-desk relationship table that identifies the relationships between employee entity instances and desk entity instances. Generating such an employee-desk relationship table would typically require human knowledge, as discussed above, about the relationships between employees and offices, and offices and desks, and further require special software development skills necessary to develop a program to generate such a structure.
Accordingly, what is needed is a mechanism for automatically generating a relationship table that identifies the relationships between entity instances of a first entity structure in a 1:1 entity structure group, and entity instances of a second entity structure in the 1:1 entity structure group.